Alpha Cloud - Alpha Anywhere Developer's Guide
Application Tuning
Symptoms - Behavior that suggests opportunities for improvement
- High Compute Unit Usage - Each Alpha Cloud plan has an included Compute Unit capacity that is usually sufficient if the deployments are consistent with the plan description.
Compute Units are the way Alpha Cloud tracks CPU utilization and requests in order to simplify charging for infrastructure services provided by Amazon and Google. Each request is charged a minimum CPU time and any CPU time actually used by your application during processing. Requests that run inefficiently can consume more CPU time than desired and result in overage charges, especially for plans that are intended for development or light duty usage.
Note: Your requirements are likely to change over time as you move from development to production and your usage grows. Initially, a small subscription plan may make sense. Once you are in production you will likely encounter overages. Be sure to contact the sales team if you see projected or actual overages so they can recommend a new plan to match your changing needs.
For more on Compute Units see Managing Usage and Costs
- Slow Response - Initial requests and callbacks should respond very quickly as this affects the user experience.
If requests are taking a long time, this can be an indication that your code is inefficient, but there can be other causes, such as not enabling connection pooling (see below).
Investigating High Compute Unit Usage and Overages
There are tools on Alpha Cloud that help identify CPU utilization and narrow down the "offending" deployment and component that are not available for on-premises deployments. Once a component is identified, tuning is no different for on-premises or Alpha Cloud. Because of this, you may find it easier to perform some tasks in the Alpha Anywhere development environment.
Follow the steps below to identify where a high usage A5W page or component is affecting your user experience:
- Finding the deployment with excessive Compute Unit Usage.
Compute units are simply a total of CPU seconds as charged on the machine. The usage data is available from within Alpha Anywhere and also using the Management Console.
Use the Subscription Usage and Costs dialog to identify which application and which deployment within that application is generating excessive Compute Unit usage.
For more complete instructions for reviewing Compute Unit Usage see The Usage and Costs Dialog
- Finding the A5W pages or components that are taking the most time.
Once an application and deployment are identified as using a lot of compute time, the next step is to identity the component (or components) responsible for the majority of the requests and/or CPU utilization.
The Cloud View dialog can be used to chart CPU/Request load by component/page. On the Cloud View dialog, you can select a time range and retrieve logs and usage data.
For instructions on viewing the CPU and requests by page/component, see The Application Requests Tab Page
- Diagnosing High Usage Code
Once you have identified a high usage page or component, your next step is to identify the Xbasic event code that is using excessive CPU time.
You can get more detailed information by profiling or adding a timing component to your UX component. In the latter case, you will see "wall clock" times, so this can be useful for Xbasic code or for overall processing time that is affected by external services and database queries (see below).
Remember that tuning an application can be done locally as well as on Alpha Cloud. You will get faster results locally, understanding that because of potential latency issues on cloud deployments, times may be increased for some actions. Profiling, for example, is a very similar process, but with profiling information going to different places.
Profiling is fairly simple to do, but does require that you add code (temporarily) to your application to investigate specific script behavior. You can add a call to profiler_begin() at the beginning of a block and then call profiler_end() at the end of the block. This will record the information to the trace window in Alpha Anywhere and to the Alpha Anywhere log on Alpha Cloud deployments.
Note: Because Alpha Cloud profiling requires republishing your application, you may want to profile locally (again, looking for smaller discrepancies) within Alpha Anywhere first.For more information on Xbasic profiling, see Profiler Begin
Investigating Slow Response
Slow pages or components can be a result of high CPU usage, but they can also be caused by misconfiguration of your application, or effects specific to cloud deployments. If you have low CPU usage, but you are still seeing slow responses check the following:
- Connection Pooling
Connecting to a database can be a very expensive operation; especially when you are using a secure connection (something you should always do on a cloud deployment). Connection pooling is a process where open connections are retained so the next SQL call is less expensive. Pooling can improve your performance dramatically if you execute many database queries as components tend to.
If you are connecting to SQL Server or PostgreSQL, then Alpha Cloud automatically configures the ODBC drivers for these databases to pool connections.
MySQL and MariaDB do not have connection pooling natively, so Alpha Anywhere implements connection pooling for you. Note that new connection strings default to enabling connection pooling, but older connection strings may not have this feature enabled. See the Advanced tab of the respective connection string dialog to be sure your connection to MySQL or MariaDB has connection pooling enabled.
- Session State
Alpha Cloud runs Alpha Anywhere Application Server for Microsoft IIS. IIS maintains session variables through a session state provider. Alpha Cloud uses a Redis service and the respective Redis Session State provider.
When executing an A5W page or component callback request, IIS must lock the session state to be sure there is no corruption of session variables. If you run multiple callbacks in parallel, this can lead to starvation of all pending requests except for the one request that has locked the sessions state. You can see this behavior visually in browser tools such as Chrome Developer Tools in that the network tab will show each request waiting in sequence until the previous one finishes.
Ideally, you want to avoid session variables when you have more than one callback executing at the same time. This is not always what you need.
In order to minimise the effect of session state locking, Alpha Anywhere includes a Just-In-Time Session State handler (JIT) that will avoid locking the session state until a reference to a session variable is executed within Xbasic. You can opt to use the JIT session state provider in the Managing Deployments Dialog
- Database Latency
When running an application on-premises, it is often the case that a database server is installed on the same machine as the running Alpha Anywhere Application Server. This practice may be reasonable for a single-server application, but for cloud deployments where application servers may be terminated or created as needed this is not a viable configuration. Alpha Cloud does not host databases, and we recommend a cloud provider for your database such as Amazon AWS Relation Database Services (RDS) because it is easy to use and robust.
An application written and run with a local database will have much different latency characteristics than a database running on another server. Many requests which execute quickly run locally can introduce tremendous delays when run in a cloud environment.
A common function used in Xbasic applications is SQL_Lookup(). This function is easy to use, and it is tempting to call it once for each field you need in a table. In a cloud environment, this can lead to tremendous slow-downs.
If you find code like this in your application, begin by retrieving all of the columns you need from a table by using SQL_Lookup_Multi() instead.
If you are running many native SQL queries from Xbasic (for exampmle to populate initial display values), consider executing them in batches, or moving the code to a stored procedure. You can return multiple result sets with a single database call and process those result sets far more quickly than separate calls.
For more information on calling stored procedures, see Stored Procedures - Database Location
We recommend deploying a database as close to the application server as possible. For example, if you are deploying your Alpha Cloud application in Virginia, London or Sydney, be sure that your Amazon RDS database is also deployed in that region.
Note: If you have already deployed your database and need to move it, follow the instructions from your cloud provider to move your database closer to your Alpha Cloud deployment. Sometimes this requires restoring a backup to a new instance of your database.
- Security Application Location
Your users and roles are deployed via a Security Application. The storage for those users and roles is in a database in a region specified by the Security Application.
Login and role retrieval may be affected if your deployment and your Security Application are in different regions.